boot: zephyr: boards: Assign boot_partition to code-patition #129

jlbwoods · 2025-06-09T18:10:30Z

Include the 2M SysBuild partitions using board variants:

rpi_pico/rp2040/mcuboot
rpi_pico/rp2040/w/mcuboot

nordicjm

this is just completely wrong, as I said before, you need to set this at the zephyr level, setting it here builds a bootloader which is setup for this and no application will work because the applications are not using the same partition layout which makes it useless

jlbwoods · 2025-06-10T16:03:57Z

this is just completely wrong, as I said before, you need to set this at the zephyr level, setting it here builds a bootloader which is setup for this and no application will work because the applications are not using the same partition layout which makes it useless

So, this means we need to have this PR approved: zephyrproject-rtos/zephyr#90758 and as you know this PR is being blocked by objections. That's why I closed the ticket and started to think about other ways to approach this.

Can you suggest how to proceed with getting the SysBuild partitions at Zephyr level?

jlbwoods · 2025-06-10T23:45:19Z

If it is not feasible to get SysBuild partitions support at Zephyr boards level and mcuboot level, maybe we can add the support in the samples level: zephyrproject-rtos/zephyr#91386

Please take a look when you have time and let me know what you think. Thanks!

nordicjm · 2025-06-11T06:36:16Z

You can add a board variant that has the partition layout, I don't see why that would be rejected, e.g. rp2350a/rp2350/mcuboot which would have rp2350a_rp2350_mcuboot.dts and in there you use the alternative partitions, that way it has full support when building anything with or without sysbuild, no files would be needed in the mcuboot repo. Pretty sure the uf2 board variant here is for a similar reason: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840

jlbwoods · 2025-06-11T17:12:03Z

You can add a board variant that has the partition layout, I don't see why that would be rejected, e.g. rp2350a/rp2350/mcuboot which would have rp2350a_rp2350_mcuboot.dts and in there you use the alternative partitions, that way it has full support when building anything with or without sysbuild, no files would be needed in the mcuboot repo. Pretty sure the uf2 board variant here is for a similar reason: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840

Okay, thank you! Will use the board variant for the partition layout!

jlbwoods · 2025-06-14T18:23:00Z

You can add a board variant that has the partition layout, I don't see why that would be rejected, e.g. rp2350a/rp2350/mcuboot which would have rp2350a_rp2350_mcuboot.dts and in there you use the alternative partitions, that way it has full support when building anything with or without sysbuild, no files would be needed in the mcuboot repo. Pretty sure the uf2 board variant here is for a similar reason: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840

Working on boards/raspiberrypi/rpi_pico/board.yml to include mcuboot variants:

board:
  name: rpi_pico
  full_name: Raspberry Pi Pico
  vendor: raspberrypi
  socs:
    - name: rp2040
      variants:
        - name: w
          variants:
            - name: mcuboot
        - name: mcuboot

Board name to use MCUboot without WiFi: rpi_pico/rp2040/mcuboot
Board name to use MCUboot with WiFi: rpi_pico/rp2040/w/mcuboot

Please advise if the above sounds okay. Thanks!

nordicjm · 2025-06-16T07:33:36Z

You can add a board variant that has the partition layout, I don't see why that would be rejected, e.g. rp2350a/rp2350/mcuboot which would have rp2350a_rp2350_mcuboot.dts and in there you use the alternative partitions, that way it has full support when building anything with or without sysbuild, no files would be needed in the mcuboot repo. Pretty sure the uf2 board variant here is for a similar reason: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840

Working on boards/raspiberrypi/rpi_pico/board.yml to include mcuboot variants:
board:
  name: rpi_pico
  full_name: Raspberry Pi Pico
  vendor: raspberrypi
  socs:
    - name: rp2040
      variants:
        - name: w
          variants:
            - name: mcuboot
        - name: mcuboot
Board name to use MCUboot without WiFi: rpi_pico/rp2040/mcuboot Board name to use MCUboot with WiFi: rpi_pico/rp2040/w/mcuboot

Please advise if the above sounds okay. Thanks!

Query for @soburi but OK to me

Include the 2M SysBuild partitions using board variants: - rpi_pico/rp2040/mcuboot - rpi_pico/rp2040/w/mcuboot Assign boot_partition to code_paritition. Signed-off-by: John Lin <john.lin@beechwoods.com>

soburi · 2025-06-17T03:31:37Z

You can add a board variant that has the partition layout, I don't see why that would be rejected, e.g. rp2350a/rp2350/mcuboot which would have rp2350a_rp2350_mcuboot.dts and in there you use the alternative partitions, that way it has full support when building anything with or without sysbuild, no files would be needed in the mcuboot repo. Pretty sure the uf2 board variant here is for a similar reason: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840

Working on boards/raspiberrypi/rpi_pico/board.yml to include mcuboot variants:
board:
  name: rpi_pico
  full_name: Raspberry Pi Pico
  vendor: raspberrypi
  socs:
    - name: rp2040
      variants:
        - name: w
          variants:
            - name: mcuboot
        - name: mcuboot
Board name to use MCUboot without WiFi: rpi_pico/rp2040/mcuboot Board name to use MCUboot with WiFi: rpi_pico/rp2040/w/mcuboot
Please advise if the above sounds okay. Thanks!
Query for @soburi but OK to me

Conceptually, mcuboot is a software configuration rather than a hardware characteristic,
so treating it as a board variant feels counter-intuitive.

jlbwoods · 2025-06-17T05:40:46Z

You can add a board variant that has the partition layout, I don't see why that would be rejected, e.g. rp2350a/rp2350/mcuboot which would have rp2350a_rp2350_mcuboot.dts and in there you use the alternative partitions, that way it has full support when building anything with or without sysbuild, no files would be needed in the mcuboot repo. Pretty sure the uf2 board variant here is for a similar reason: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840

Working on boards/raspiberrypi/rpi_pico/board.yml to include mcuboot variants:
board:
  name: rpi_pico
  full_name: Raspberry Pi Pico
  vendor: raspberrypi
  socs:
    - name: rp2040
      variants:
        - name: w
          variants:
            - name: mcuboot
        - name: mcuboot
Board name to use MCUboot without WiFi: rpi_pico/rp2040/mcuboot Board name to use MCUboot with WiFi: rpi_pico/rp2040/w/mcuboot
Please advise if the above sounds okay. Thanks!
Query for @soburi but OK to me
You can add a board variant that has the partition layout, I don't see why that would be rejected, e.g. rp2350a/rp2350/mcuboot which would have rp2350a_rp2350_mcuboot.dts and in there you use the alternative partitions, that way it has full support when building anything with or without sysbuild, no files would be needed in the mcuboot repo. Pretty sure the uf2 board variant here is for a similar reason: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840

Working on boards/raspiberrypi/rpi_pico/board.yml to include mcuboot variants:
board:
  name: rpi_pico
  full_name: Raspberry Pi Pico
  vendor: raspberrypi
  socs:
    - name: rp2040
      variants:
        - name: w
          variants:
            - name: mcuboot
        - name: mcuboot
Board name to use MCUboot without WiFi: rpi_pico/rp2040/mcuboot Board name to use MCUboot with WiFi: rpi_pico/rp2040/w/mcuboot
Please advise if the above sounds okay. Thanks!
Query for @soburi but OK to me
Conceptually, mcuboot is a software configuration rather than a hardware characteristic, so treating it as a board variant feels counter-intuitive.

PR using variants:
zephyrproject-rtos/zephyr#91735

jlbwoods · 2025-06-17T05:48:20Z

Conceptually, mcuboot is a software configuration rather than a hardware characteristic, so treating it as a board variant feels counter-intuitive.

Any other alternatives to add mcuboot and it's SysBuild partitions under Zephyr? I think rpi_pico/rp2040/w is a very special case board type different than other types of SOC's/boards's.

soburi · 2025-06-17T20:23:32Z

Conceptually, mcuboot is a software configuration rather than a hardware characteristic, so treating it as a board variant feels counter-intuitive.

Any other alternatives to add mcuboot and it's SysBuild partitions under Zephyr? I think rpi_pico/rp2040/w is a very special case board type different than other types of SOC's/boards's.

The fundamental problem is that there is no way to configure boards when sysbuild-ing.
For example, I think it is necessary to consider a way to configure board-specific settings that are applied at sysbuild time, such as
boards/raspberrypi/rpi_pico/sysbuild.overlay.
This will take some time to solve, but it's better not to limit the solution to rpi_pico.

About for this PR, the overlay to be applied to this mcuboot should be ok as below.
I think it's fine for mcuboot to require sysbuild settings as a prerequisite.

boot/zephyr/boards/rpi_pico_rp2040.overlay
boot/zephyr/boards/rpi_pico_rp2040_w.overlay

jlbwoods · 2025-06-18T04:25:09Z

Conceptually, mcuboot is a software configuration rather than a hardware characteristic, so treating it as a board variant feels counter-intuitive.

Any other alternatives to add mcuboot and it's SysBuild partitions under Zephyr? I think rpi_pico/rp2040/w is a very special case board type different than other types of SOC's/boards's.

The fundamental problem is that there is no way to configure boards when sysbuild-ing. For example, I think it is necessary to consider a way to configure board-specific settings that are applied at sysbuild time, such as boards/raspberrypi/rpi_pico/sysbuild.overlay. This will take some time to solve, but it's better not to limit the solution to rpi_pico.

About for this PR, the overlay to be applied to this mcuboot should be ok as below. I think it's fine for mcuboot to require sysbuild settings as a prerequisite.
* `boot/zephyr/boards/rpi_pico_rp2040.overlay`

* `boot/zephyr/boards/rpi_pico_rp2040_w.overlay`

Do you have more info for sysbuild.overlay? Cause I tried that and it's not working!

soburi · 2025-06-18T04:38:46Z

Do you have more info for sysbuild.overlay? Cause I tried that and it's not working!

This is an example of how we need to add functionality like this.
Since there is no such feature, we need to propose adding it to the build system and then implement it.

As a temporary workaround, defining overlays in each app should be fine.
So, if we are going to fix it, it should be a fundamental solution.

In other words, the problem is that there is no mechanism to apply settings in conjunction with sysbuild, so I think it would be best to raise that issue first.

jlbwoods · 2025-06-18T06:11:26Z

Okay, got it! In the mean time, should we go ahead and use the variant method for now?

…

On Tue, Jun 17, 2025, 9:39 PM TOKITA Hiroshi ***@***.***> wrote: *soburi* left a comment (zephyrproject-rtos/mcuboot#129) <#129 (comment)> Do you have more info for sysbuild.overlay? Cause I tried that and it's not working! This is an example of how we need to add functionality like this. Since there is no such feature, we need to propose adding it to the build system and then implement it. — Reply to this email directly, view it on GitHub <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATRRPBFYRU67R3LPPYBEEPL3EDUOZAVCNFSM6AAAAAB65SGLBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBSGY2DOMJWHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

nordicjm · 2025-06-18T06:20:26Z

Conceptually, mcuboot is a software configuration rather than a hardware characteristic, so treating it as a board variant feels counter-intuitive.

Any other alternatives to add mcuboot and it's SysBuild partitions under Zephyr? I think rpi_pico/rp2040/w is a very special case board type different than other types of SOC's/boards's.

The fundamental problem is that there is no way to configure boards when sysbuild-ing. For example, I think it is necessary to consider a way to configure board-specific settings that are applied at sysbuild time, such as boards/raspberrypi/rpi_pico/sysbuild.overlay. This will take some time to solve, but it's better not to limit the solution to rpi_pico.

About for this PR, the overlay to be applied to this mcuboot should be ok as below. I think it's fine for mcuboot to require sysbuild settings as a prerequisite.
* `boot/zephyr/boards/rpi_pico_rp2040.overlay`

* `boot/zephyr/boards/rpi_pico_rp2040_w.overlay`

The point in board variants is for exactly that, to provide alternative software-defined parts (note: not needing hardware changes). Most other boards already have an MCUboot-style partition layout so they do not offer one. Having files like that in MCUboot is not useful because apps will absolutely not work with it and would need files duplicated in them, and we're not about to duplicate those files in lots of samples in zephyr so specific samples can build on those boards, with a board variant then no files are needed in any samples or any other repos and it doesn't impact any existing users, but users wanting to build for MCUboot can then do so.

From https://docs.zephyrproject.org/latest/glossary.html#term-variant

In the context of board qualifiers, a variant designates a particular type or configuration of a build for a combination of SoC and CPU cluster. Common uses of the variant concept include introducing both secure and non-secure builds for platforms with Trusted Execution Environment support, or selecting the type of RAM used in a build.

Good example is this board: https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/adafruit/feather_nrf52840 it has the normal board and a uf2 variant, normal one includes this partition layout: https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/vendor/nordic/nrf52840_partition.dtsi which is MCUboot compatible, the uf2 variant has this partition layout: https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/vendor/nordic/nrf52840_partition_uf2_sdv6.dtsi which is not MCUboot compatible, and users can pick which one to build for

The alternative is no support is added and users do it with a board extension out of tree

soburi · 2025-06-18T07:04:52Z

Thank you for your clarification. > @nordicjm

I was misunderstood at this point.

The point in board variants is for exactly that, to provide alternative software-defined parts

Referring to the policy, there is no problem with this PR.
There is already a working example like the one you showed; it's best to follow that.

@jlbwoods
Let's go with that.

jlbwoods · 2025-06-18T15:27:10Z

Thank you for your clarification. > @nordicjm

I was misunderstood at this point.

The point in board variants is for exactly that, to provide alternative software-defined parts

Referring to the policy, there is no problem with this PR. There is already a working example like the one you showed; it's best to follow that.

@jlbwoods Let's go with that.

Also, before merging this PR, we need approval for this boards: variants PR first: zephyrproject-rtos/zephyr#91735

jlbwoods requested review from nordicjm and de-nordic as code owners June 9, 2025 18:10

jlbwoods mentioned this pull request Jun 9, 2025

boot: zephyr: boards: Assign boot_partition to code-patition #128

Closed

nordicjm requested changes Jun 10, 2025

View reviewed changes

boot: zephyr: boards: Assign boot_partition to code-patition

bac82a7

Include the 2M SysBuild partitions using board variants: - rpi_pico/rp2040/mcuboot - rpi_pico/rp2040/w/mcuboot Assign boot_partition to code_paritition. Signed-off-by: John Lin <john.lin@beechwoods.com>

jlbwoods force-pushed the pr_upstream-sync_boot_zephyr_boards_pico branch from bd2fbff to bac82a7 Compare June 17, 2025 05:01

jlbwoods requested a review from nordicjm June 17, 2025 05:51

jlbwoods mentioned this pull request Jun 18, 2025

boards: raspberrypi: rpi_pico: Use sysbuild.overlay zephyrproject-rtos/zephyr#90758

Closed

soburi approved these changes Jun 18, 2025

View reviewed changes

jlbwoods mentioned this pull request Jun 21, 2025

boards: raspberrypi: rpi_pico: Add MCUboot variants zephyrproject-rtos/zephyr#91735

Open

boot: zephyr: boards: Assign boot_partition to code-patition #129

Are you sure you want to change the base?

boot: zephyr: boards: Assign boot_partition to code-patition #129

Conversation

jlbwoods commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nordicjm left a comment

Choose a reason for hiding this comment

Uh oh!

jlbwoods commented Jun 10, 2025

Uh oh!

jlbwoods commented Jun 10, 2025

Uh oh!

nordicjm commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jlbwoods commented Jun 11, 2025

Uh oh!

jlbwoods commented Jun 14, 2025

Uh oh!

nordicjm commented Jun 16, 2025

Uh oh!

soburi commented Jun 17, 2025

Uh oh!

jlbwoods commented Jun 17, 2025

Uh oh!

jlbwoods commented Jun 17, 2025

Uh oh!

soburi commented Jun 17, 2025

Uh oh!

jlbwoods commented Jun 18, 2025

Uh oh!

soburi commented Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jlbwoods commented Jun 18, 2025 via email

Uh oh!

nordicjm commented Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

soburi commented Jun 18, 2025

Uh oh!

jlbwoods commented Jun 18, 2025

Uh oh!

Uh oh!

jlbwoods commented Jun 9, 2025 •

edited

Loading

nordicjm commented Jun 11, 2025 •

edited

Loading

soburi commented Jun 18, 2025 •

edited

Loading

nordicjm commented Jun 18, 2025 •

edited

Loading